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(54) Bridge providing communication between different implementations of object request 
brokers 



(57) Systems and methods for providing communi- 
cation between different implementations of object re- 
quest brokers are provided. A bridge including a proxy 
object allows communication between the object re- 
quest brokers. The proxy object within the bridge stores 



the server object reference in its reference data. The 
proxy object translates messages (e.g., requests and 
responses/exceptions) to the transfer protocol of the 
server object and redirects these messages according 
to the server object reference stored in the proxy ob- 
ject's reference data. 
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Description : • - • ■ . c 

The present invention relates to object-oriented 
computer systems. In particular, the present invention 
is concerned with a bridge allowing communication be- 
tween different implementations of object request bro- 
kers. 

As individual computer systems increasingly be- 
come more powerful and complex, the integration of 
these heterogeneous computer systems becomes a 
very desirable yet difficult task. Users' expectations for 
interoperability have increased dramatically due to the 
availability of highly interoperable 1 platforms such as 
UNIX, Microsoft VVindows and Apple'Macihtosh. Unfor- 
tunately, vendor-specific 7 feolutionslpr integrating heter- 
ogeneous dbmpOter' systerhs 'have geh^ally teen un- 
satisfactory. This is especially triia because vendor-spe- 
cific solutions require upgrades to take into aoioont new 
product risfeasdk " '* ; ' r ' '" ' : ! 

The Objbct 1 litenagerhent Group (OMG) has : prom- 
ulgated standards for Pionveridor-specific sdlufibhs'for 
heterogeneous ^ the h&art of 

OMG's 6tancferd is ; the Common Objeict ReqitestBrbker 
Architecture (CORBA). bdRBA is a distributed eriVlrbn- 
meht defined ushg^ject^idnted fe^ all 
difference's' between programming languages, operat- 
ing systems; hardw^rd platfoirns, arid object' location. 
This interoperability is achieved through well-defined in- 
terlace spebificdttdns at the application level. ; / 

: Well-defined protocols exist for allowing systems to 
communicate by agreeing to certain standards that will 
be used. The Open Systems Interconnection '(0"§l) sev- 
en layer model is possibly the most widespread of these 
protocols. The lowest layer, : the Physical layer, de- 
scribes how the physical network is accessed. The Data 
Link layer provides reliable transmission across a phys- 
ical link; The Network layer deals with connection es- 
tablishment and routing. The' Transport layer provides 
reliable end-to-entf transmission. The Session layer is 
concerned with connection control. The Presentation 
layer deals with I date syntax and transparency to the ap- 
plications. Lastly, the upper leryer, the Application layer, 
describes end-user functionality. Conceptually; CORBA 
resides in the Application layer. 

A central component of CORBA is ; the Object Re- 
quest Broker (ORB) which is the infrastructure for pro- 
viding transparent distributed communication 'across 
heterogeneous systems. The CORBA specification de- 
scribes all the 1 standard interfaces for ORBs. The Basic 
Object Adapter (BOA) is an initial set of ORB interfaces 
for object-implementations. 

CORBA is a peer-to-peer distributed computer fa- 
cility where all applications are objects. Objects can al- 
ternate between being a client and a server, where a 
client object is defined as being the originator of an ob- 
ject invocation arid a : server object is defined as being 
the recipient of an object invocation. Server objects are 
also referred to as object implementations. Typically, ob- 



jects play both roles at one time or another. 

CORBA provides two mechanisms with or through 
which applications may communicate: static interfaces 
and dynamic interfaces. In static interfaces, the param- 

s eters are defined at compile-tirhe whereas in dynamic 
interfaces; the parameters are'deifined at run-time. : 

Sffatic interfaces include a stub and a skeleton. The 
client object links to the stub so that from the client's 
perspective, the stub acts like & local function call. 

10 Transparently, the stub provides ah interface to the ORB 
that encodes and decodes the specified operation's pa- 
rameters into communication formats suitable for trans- 
mission. The skeleton is the corresponding server-side 
implementation of the interface;' When the server object 

*s completes processing of the request, the skefeton and 
stub return the results to the client, along with any ex- 
ceptions that are generated by either the server or the 
ORB v ' 

Dynamic interfaces are ah alternative to compiled 
20 static interfaces. Dynamic interfaces include a Dynamic 
Invocation Interface (Dll) arid a Dynamic Skeleton Inter- 
face (DSIJ, The Dli is a generic facility' for invoking any 
operation With a run-tiriW-definecf parameiter list' A run- 
time Interface description of the operation signature 
25 specifying theparameter list is retrieved during run-time. 
Thus, a request can be constructed to previously un- 
known bpdr^tiori or object typd. fite tiSI is the corre- 
sponding server-side implementation of the interface. 
Use of the dynamic interface instead of the static inter- 
so face is transparent to object implementation. 

Current CORBA ORB products support software in- 
tegration across multiple platforms! ORB implementa- 
tions may be generic across multiple platforms or plat- 
form-specific. Platform-specific ORB implerhentations 
35 offer many advantages including more efficient imple- 
mentation resulting from closer tiesto the operation sys- 
tem. As an example, Sun Microsystems' NEO provides 
shared services extensions tb the Solaris operating sys- 
tem. NEO supports standards such as OMG'e CORBA 
40 specifications. * ■ ' 

Although platform-specific implementations of 
CORBA offer many advantages, there is a need for more 
efficient systems and methods for providing communi- 
cation between different implementations of ORBs, 
45 Embodiments of the present invention provide in- 
novative systems and methods for providing communi- 
cation between different implementations of object re- 
quest brokers. A bridge including a proxy object allows 
communication between the object request brokers. 
so The proxy object within the bridge stores the server ob- 
ject reference in its reference data. The proxy object 
translates messages (e.g., requests and responses/ex- 
ceptions) to the transfer protocol of the server object and 
redirects these messages according to the server object 
55 reference stored in the proxy object'6 reference data. 
Thus, an efficient mechanism for providing communica- 
tion between different implementations of object request 
brokers is achieved. 
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In one embodiment, the present invention provides 
a method of providing, communication between a first 
object request broker utilizing a first transport protocol 
and a second object request broker utilizing a second 
transport protocol, comprising the steps of: storing with- 
in the reference data of a proxy object a reference to a 
server object; the proxy object receiving a request.in the 
first transport protocol from a client object on the first 
. Object request broker; the proxy object translating the 
request to the second transport protocol; and the proxy 
object sending the translated request to the server ob- 
ject specified by the stored reference. 

In another embodiment, the present invention pro- 
vides a system for providing communication between 
different implementations of object, request brokers, 
comprising: a first object request broker utilizing a first 
transport protocol; a client object on the first object re- 
quest broker; a second object request broker utilizing a 
second transport protocol, the first and second transport 
protocols being different; a server object on the second 
object request broker; and a proxy object that translates 
a request in the first transport protocol .from the client 
object to the. second transport protocol and sends the 
v translated request tp the server object specified by a ref- 
erence to the'server.object stored in the reference data 
of the proxy object. ' 

The invention is described further hereinafter, by 
way of example i only, with reference. to,the accompany- 
ing drawings, in which:- 

Fig. 1 illustrates an example of a computer system 

used to execute the software of an embodiment of 

the present invention; , , 

Fig. 2 shows a system block diagram of a typical 

computer system used to execute the software of 

an embodiment of the present invention; 

Fig. 3 is a block diagram of the interfaces between 

CORBA objects; 

Fig. 4 is a block diagram of a NEO bridge connect- 
ing to two different implementations of ORBs; 
Fig. 5 shows that the bridges of embodiments of the 
. present invention provide bidirectional communica- 
tion between ORBs; 

Fig. 6 shows the high level architecture of a bridge; 
Fig. 7 shows components inside an embodiment of 
the bridge; 

Fig. 8A shows a block diagram of a NEO client ob- 
ject invoking a server object on another ORB; 
Fig. BB is a high level flowchart of a process of a 
NEO client invoking a server on another ORB; 
Fig. 9A shows a block diagram of a client object on 
another ORB invoking a server object on a NEO 
ORB; and 

Fig. 9B.is a high level flowchart of a process of a 
client on another ORB invoking a server on a NEO 
ORB. 

In the description that follows, embodiments of the 



present invention will be described in reference to NEO 
ORBs on a Sun workstation running under the Solaris 
operating system. The present invention, however, is 
npt limits^ to any particular ORB implementation, com- 
5 puter architecture or operating systern. Additionally the 
.following describes communication between two ORBs, 
but communication among multiple ORBs may be ac- 
complished by an extension of the principles described 
herein. Therefore, the description the embodiments that 
10. follow is for purposes of illustration and not limitation. 
Fig. 1 illustrates an example of a computer system 
used to execute the software of an embodiment of the 
present invention. Fig. 1 , shows a computer system 1 
which includes a^pnitor 3, screen 5i cabinet 7, key- 
is boar^Q.^dmoMse^l. Mouse 11 may have>oneormore 
buttons sgch as mouse bujtpns 13. Cabinet 7 houses a 
CP-ROM ^riye.15, a-system memory and a hard drive 
(see Fig. £) which may be utilized to store and retrieve 
software i programs incprptprating pode that implements 
20 the present invention, data for use with the present in- 
vention, and the like. Although a CD-ROM 17 is shown 
as an exemplary computer, rbadabje storage medium, 
other computer readable storage media incjuding floppy 
disks, tape, flash memoiy, system- me and hard 
25 drives may jaa utiiized. Cabinet 7. also houses familiar 
computer components (not .shown) such as. a central 
processor, system memory, hard disk, and the like. 

. Frig, 2 shows a system block diagram of computer 
system' j usee), to execute the ^oftvvare pf an embodi- 
30 meni of the present invention. As in Fig. 1, computer 
system 1 includes monitor 3 and keyboard 9. Computer 
system 1 further includes subsystems such as a central 
processor 102, system memory 104J/O controller 106, 
display adapter 108, removable disk 112 (e.g., CD-ROM 
35 drive), fixed disk 116,(e.g„ hard drive), network interface 
118, and speaker 1 20. Other computer systems suitable 
for use with the present jnvention may include additional 
. or fewer subsystems. For example, another computer 
.system could include more than one processor 102 (i. 
4£> e. t a multiprocessor system) or a cache memory. 

Arrows such as 122 represent the system bus ar- 
chitecture of computer system 1 . However, these arrows 
are illustrative of anylnterconnectipn scheme serving to 
link the subsystems; for example, a local bus could be 
45 utilized to connect the central processor to the system 
memory and display adapter.. Computer system 1 
shown in Fig, 2 is but an example of a computer system 
suitable for use with the present invention. Other con- 
figurations of subsystems suitable for use with, the 
50 present invention will be readily apparent to one of or- 
dinary skillin. the art. 

Fig. 3 is a block diagram.of the static and dynamic 
interfaces between objects in CORBA. A client object 
202 makes requests to an object implementation 204 
55 (also called a "server object" as it services client re- 
quests). The.torms client and server are relative terms. 
A client may be a client with respect to a specrfic.request 
and a server with respect to another request. Conse- 
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quently, these labels will vary accordfng to the circum- 
stances. 

A client may also make a request utilizing a dynamic 
interface by calling a DM 214. The Dll provides an inter- 
face to ORB cbnB 208 that encodes and decodes the 
specified operation's parameters into communication 
formats suitable for transmission over the transfer me- 
dium, the Dll is dynamic because the parameter list is 
defined at run-time. 

After a request is encoded and transmitted over the 
transfer medium, the request is decoded and passed to 
object adapter 21 ft If the specified object implementa- 
tion utilizes a dynamic interface, skeleton 212 (DSI in 
this case) provides a callback to a function implemen- 
tation for the request. The client and server object 'may 
also Interact directly with the* ORE* core in rbugh an ORB 
interface 216. • • ' ; ; * - - * 

It should be noted that the format of the request is 
the same over the transfer medium "regardless ot wheth- 
er a static or dynamic interface is utilized. In' a; preferred 
embodiment, the client' and server objects utilize '& dy- 
namic interface. ; : - - v> ^» -r-y 

A general 1 protocol for communicating between 
ORBs is thVftttmetli^ Protocol (HOP). II- 

OP is bas6d on TrahsmisstorTckintrbl Protbcbwfhfernet 
Protocol (TCP/IP) which &the protocol of tfiel Iptdrhet. 
AddKloh^iliy, I lOP^ is sjp^cffjcaliy dtrecWd tb ORB-to-ORB 
interoperability! j n thd de^Hptfdn that followk; ORBis will 
be described as utilizing HOP tb comrhunid^tis; Howev- 
er, the use of this protocol is for illustrative purposes and 
other protocols m^be utilized With the : present inven- 
tion. ■ :i : - - ; - ■■ ; ' : 

Fig: 4 is a block diagram i of a NEO bridge connect- 
ing two different implementations of ORBs. By diffbrent 
implementations (or types') of ORBS, it is meantthat fhe 
ORBs utilize different tr^nsporl'protocote. ANEO ORB 
302 includes a bridge 304 which provides communica- 
tion with different implementations of ORBs. : 

An ORB $06 utilizes HOP asits transport protocol 
which Is a different transport protocol utilized by NEO 
ORBs, which utiliid Distributed Object Maniagement Fa- 
cility (DOMF). BTidge'304 allows NEO ORB 302 to* com- 
municate with ORB" ^06 utilizing HOP; Although the 
bridge is shown in the NEO ORB; the bridge may alter- 
natively be in ORB 306 in either' case, the bridge pro- 
vides bidirectional cbrhmOnication between the different 
implementatibriVof ORBs. • ? *■■'■* 

Also in Fig. 4, an- ORB 308 includes a bridge 31 0. 
ORB 308 uses a transport protocol other than HOP. In 
this instance, bridges 304 and 31 0 provide communica- 
tion between ORBs 302 and 308 utilizing an intermedi- 
ate transport protocol of HOP. Thus, two bridges provide 
full interoperability between NEO ORB 302 and ORB 

308; 

Fig. 5 shows that the bridges of embodiments of the 
present invention provide bidirectional communication 
between different implementations of ORBs. In order to 
achieve full interoperability, a bridge should allow both 



a client object on a NEO ORB to invoke a server object 
on another ORB.and a client object on another OFIB to 
invoke a server object on the NEO ORB. Typically, the 
bridge is hosted atop some ORB (e.g., the NEO ORB). 
5 As shown, a client 352 on a NEO ORB 354 may 
request tb invoke a server 355 on an ORB 356. The cli- 
ent makes a request through the NEO ORB to a bridge 
357 which resides on the NEO ORB. the bridge is an 
application on the ORB that includes a proxy object 358. 
10 By proxy objeci it is meant ah object that translates land 
redirects requests to a server object, thus, the proxy 
object translates Xh6 request and sends the request to 
server 355. The server sends a response (or. exception) 
back to the proxy object which translates the response 
before* sending the response to the client through the 
NEOORB. 

Client 352 utilizes a local object reference for the 
proxy object because the client and proxy are on the 
same ORB. Hovtever, the server is on a different ORB 

20 so 1he proxy object utilizes a nonlocal or foreign object 
reference for the server. In order to more efficiently proc- 
ess the translation of the local object reference of the 
proxy to the nonlocal object reference of the server, the 
proxy object stores > Within its r^ferencfe data'the hpnlocal 

25 object reference of the served ; . 

: The reference data is a stooge space within many 
bbjects. For example, in Basic Object Adapter 1 (BOA), 
objects, the ref erence data space is 1 K bytes. Thus, the 
nonlocal (or local as discussed in the following para- 

30 graphs) object reference fbr thb server may be stored 
in the Reference dat?i of the proxy object. In a preferred 
embodiment, tRe object references for the server are 
stored as 'strings. ' 

• ^ Additionally, k nonlbcaf client object may request to 

35 invoke a local servfei 1 object. As shown in Fig: 5, a client 
360 iri ORB 3S6 rriay requesrto invoke a server 362 on 
NEO OR6 35~4. The clfeht makes a request to a proxy 
object 364 in i the bridge. The'prbxy object translates the 
request before' it is sent to th^6erveV through the NEO 

to ORB : . The server Sends a response (or exdeption) back 
thrbugh the NEO ORB to the proxy object The proxy 
object translates the response arid sends it to the client 
through the ORB on Which it resides. The" proxy- object 
stores the local object Reference of the 'server in the ref- 

& erence data of the proxy object. r ? : 

Fig. 6 shows the high level architecture of a bridge. 
In a preferred embodiment, the bridge receives requests 
from two interfaces: DOMF and HOP. Communication 
between the bridge and NEO objects utilizes the DOMF 

so transfer protocol (e.g., including Dll and DSI). Commu- 
nication between the bridge and an object on other im- 
plementations of ORBs utilizes the HOP transfer proto- 
col. For example, a request from a client on a NEO ORB 
402 to a server on another ORB 404 is sent to a bridge 

55 406 via DSI DOMF. The bridge translates the DSI re- 
quest to an Dll HOP request. The response/exception is 
then received by the bridge via Dll and the bridge trans- 
lates it back to a DSI DOMF response/exception. 
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Also, a request from a client on ORB 404 to a server 
on NEO ORB 402 is sent to the bridge via DSI MOR The 
bridge, translates the DSI request to a Djl DOMF re- 
quest. The response/exception is then received by the 
bridge via Dll arid the bridge translates it back to a DSI 
NOR response/exception. 

. -The MOP transfer protocol may be implemented in 
the.bridgLe innumerous ways including embedding MOP 
in the bridge itself (thus, the NEO ORB. core, does not 

. need to change) or modifying the host ORB to provide . 
dual transport stacks, of the DOMF and HOP transfer 
protocols. The first approach may be preferable as it is 
believed to be more efficient and portable. 

Fig. .7 shows components inside an embodiment of 
the NEO ORB bridge. In a preferred embodiment, the 
bridge includes two main parts: 1) the HOP implement 
tation that contains the MOP transfer protocol (with part 
of the ORB interface) and 2) the bridge core that con- 
tains the code for translating DOMF requests/responses 
to ilOP requests/responses, (and vjce versa), The first 
part is portable across several UNIX platforms. The sec- 
ond part is not necessarily portable since it interfaces 
with DOMF which may not be available in .every ORB 
implementation.. 

The bridge serves as the connecting entity between 
two ORBs, therefore a bridge is preferably automatically .. 
started after a machine is rebooted. A bridge may be 
Implemented as a DOMF self-starting (persistent) serv- 
er. .. '" ' \ 

Fig. 8A shows a block diagram of a NEO client in- 
voking an object pn another ORB. A NEO ORB 502 in- 
cludes a client 504 and a, bridge 506. The bridge in- 
cludes a proxy object 508 which has a storage space of 
reference data 51 0. Another ORB 512 includes a server 
51 4. ORB 514 is a different implementation of NEO ORB 
502 as it does not utilize the same transfer protocol. 

If the client desires to invoke the server, the client 
sends a request to the local prpxy object. The proxy ob- 
ject translates the request into the transfer protocol of 
ORB 512 (e.g., HOP) and retrieves the nonlocal object 
reference of the server from reference data 510. The 
proxy object then sends the translated request to the 
server specified by the retrieved object reference. ■ 

Proxy object 508 will receive the response (or ex- 
ception) from the server and translates the response to 
the transfer protocol of the NEO ORB. The proxy object 
then. sends the translated response to the client on the 
NEO ORB. 

Fig. 8B is a high, level flowchart of a process of a 
NEO client invoking a server on another ORB. At step 
552, the NEO ORB receives a request from one of its 
clients via DSI that specifies a server on another ORB. 
The bridge queries the NEO ORB's object references to 
retrieve parameter and exception definitions for the re- 
quest at step 554. At step 556, the proxy object finds the 
server object's reference from the DOMF proxy object 
reference data. 

The proxy object translates all the DOMF specific 
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data types to IlOP data types at step 558. Once all the 
necessary, data types are translated, the proxy object 
sends the request out via the Dll MOP interface to the 
other ORB at step 560. _ , . . / 

s . At step 562, the proxy object receives the response/ 
. exception from the Dll MOP interface from the other 
. ORB. In order-to prepare.the response forthe.client. the 
proxy object translates all the NOP specific data types 
to DOMF data types at step 564. Once the response is 
, 10 formatted for the client, the response/exception is sent 
back to the client via DSI at step 566. 

Fig. 9A shiows a block diagram of a client on another 
ORB invoking a server on a NEO ORB. t A NEO ORB 
602 includes a server 604 and a bridge 606. The bridge 
is includes a proxy object 608 which has a storage space 
. : of reference data 61 0 : Another ORB 612 jncludes a cli- 
ent 61 4. ORB 61 4 is a different implementation of NEO 
ORB 602 as it does not utilize the same transfer proto- 

20 i - if the client .desires, to invoke the server, the client 
r sends, a request to the nonlocal proxy object. utilizing a 
local object reference. The, proxy object translates the 
request into the transfer protocol of NEO ORB ,602 (e. 
. g. , DOMF) and retrieves the local object reference of the 
25 , server from reference data .610. The proxy object then 
sends the translated request to the server specified by 
the retrieved object reference. 

Proxy object 608 will /eceive the response (or ex- 
, ception) from the server and translates the response to 
30 the transfer, protocol of ORB 61 2. : The proxy object then 
sends the translated response to the client on ORB 61 2. 
...... Fig. 9B is a high level flowchart of a process of a 

client on another ORB invoking a server on a NEO ORB. 
At step 652, the NEO ORB receives a request from a 
35. client on the other ORB via DSI HOP that specifies a 
server on the NEO ORB. The proxy object queries the 
NEO ORB's object references to retrieve parameter and 
exception definitions for the request at step 654. At step 
656, the proxy object finds the server object's reference 
to from the DOMF proxy object reference data. 

The prpxy object translates all the MOP specific data 
types to DOMF data types at step 658. Once all the nec- 
essary data types are translated, the proxy object sends 
the request out via DM to the NEO server at step 660: 
45 At step 662, the proxy object receives the response/ 
exception from the Dll interface from the server. In order 
to prepare the response for the client, the proxy object 
translates all the DOMF specific data types to I IOP data 
types at step 664. Once the response is formatted for 
so the client,- the response/exception is sent back to the 
client on the other ORB via DSI HOP at step 666. 

While the above is a complete description of pre- 
ferred embodiments of the invention, various alterna- 
tives, modifications and equivalents may be used. It 
55 should be evident that the present invention is equally 
applicable by making appropriate modifications to the 
embodiments described above. Fo r example, embodi- 
ments have been described for providing communica- 
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tion between a NEO ORB and another ORB. However, 
the invention may be utilized to provide communication 
between many different implementations of ORBs. 
Therefore, the above description should not be taken as 
limiting the scope of the invention which is defined by 
the metes and bounds of the appended claims and their 
full scope of equivalents. 



Claims 

1 . A method of providing communication in a computer 
system between a first object request broker utiliz- 
ing a first transport protocol and a second object re- 
quest broker utilizing a second transport protocol, 
comprising the steps of: 

storing within the reference data of a proxy ob- 
ject a reference to a server object; 
the proxy object receiving a request in the first 
transport protocol from a client object on the 
first object request broker; 
the proxy object translating the request to the 
second transport protocol; and 
the proxy object sending the translated request 
to the server object specified by the stored ref- 
erence. 

2. The method of claim 1 , wherein the translating step 
includes the step of translating all data types in the 
request that are specific to the first transport proto- 
col to the second transport protocol. 

3. The method of claim 1 , further comprising the step 
of the proxy object receiving a response in the sec- 
ond transport protocol from the server object on the 
second object request broker. 

4. The method of claim 3, further comprising the 6tep 
of the proxy object translating the response to the 
first transport protocol. 

5. The method of claim 4 t "further comprising the step 
of the proxy object sending the translated request 
to the client object. 

6. The method of claim 3, further comprising the step 
of translating all datatypes in the response that are 
specific to the second transport protocol to the first 
transport protocol. 

7. The method of claim 1 , wherein the proxy object is 
in a bridge application. 

8. The method of claim 1 , wherein the proxy object is 
located on the first object request broker. 

9. The method of claim 1, wherein the first transport 
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. protocol is DOMF. 

The method of claim 1 , wherein the second trans- 
port protocol is HOP. 

A cbrinputer program product for providing commu- 
nication between a first object request broker utiliz- 
ing a first transport protocol and a second object re- 
quest broker utilizing a second transport protocol, 
comprising: 
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a computer readable storage medium storing a 
computer program comprising: 
code that stores within the reference data of a 
proxy object a reference to a server object; 
code for the proxy object that translates a re- 
quest in the first transport protocol from a client 
object on the first object request broker to the 
second transport. protocol; and 
code for the proxy object that sends the trans- 
lated request to the server object specified by 
the stored reference. 

12. The computer program product of claim .11 . further 
comprising codB that translates all data types in the 
request that are specific to the first transport proto- 
col to the second transport protocol. 

13. The computer program product of claim 11 , further 
comprising code for the proxy object that translates 
a response in the second transport protocol from 
the server on the second object request broker to 
the first transport protocol. 

14. The computer program product of claim 1 3, further 
comprising code for the proxy object that sends the 
translated request to the client object. 

16. The computer program product of claim 13, further 
comprising code that translates all datatypes in the 
response that are specific to the second transport 
protocol to the first transport protocol. 



16. The computer program product of claim 11 , wherein 
& the proxy object is declared in a bridge application. 

17. The computer program product of claim 11 , wherein 
the proxy object is on the first object request broker. 

so 18. The computer program product of claim 11 , wherein 
the first transport protocol is DOMF. 



1 9. The computer program product of claim 1 1 , wherein 
the second transport protocol is HOP 

20. A system for providing communication between dif- 
ferent implementations of object request brokers, 
comprising: 
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a first object request broker utilizing a first 
transport protocol; 

a client object on the first object request broker; 
a second object request broker utilizing a sec- 
ond transport protocol, th6 first arid second s 
transport protocols being different; 
a server object on the second object request 
broker; and 

a proxy object that translates a request in the 
first transport protocol from the client object to 10 
the second transport protocol and sends the 
translated request to the server object specified 
by a reference to the server object stored in the 
reference data of the proxy object. 

15 

21. The system of claim 20, wherein the proxy object 
translates all data types in the request that are spe- 
cific to this first transport protocol to the second 
transport protocol. 

'•'■■'.* 20 

22. The system of claim 20, wherein the proxy object 
translates a response in the second transport pro- 
tocol from the server on the second object request 
broker to the first transport protocol. 

25 

23. The system of claim 22, wherein the proxy object 
sends the translated request to the client object. 

24. The system of claim 22, wherein the proxy object 
translates all data types in the response that are 30 
specific to th6 second transport protocol to the first 

: transport protocol. 

25. The system of claim 20, further comprising a bridge 
application that includes the proxy object. 35 

26. The system of claim 20, wherein the proxy object is 
on the first object request broker.' 

27. The system of claim 20, wherein the first transport 40 
protocol is DOMR 

28. The system of claim 20, wherein the second trans- 
port protocol is MOP. 

45 
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